\chapter{Conclusões}

\section{Análise e classificação}
Como os resultados mostraram, as ferramentas de ataque desenvolvidas nesse documento conseguem atrasar bastante o tempo de resposta
de um servidor pequeno mas bem equipado, consequentemente degradando o serviço para o cliente. Apesar do servidor não ter sofrido uma negação
de serviço total, o ataque é viável e pode ser melhorado em alguns aspectos. O ataque pode evoluir rapidamente se tornando uma ameaça e
cabe aos estudioso da área de segurança de redes planejar métodos de minimizar os efeitos do ataque antes que o mesmo se torne
popular.

Os resultados obtidos foram todos realizados em ambiente controlado e isolado para uma medição mais precisa, mas, em ambiente real, 
estipula-se que o ataque seja bem mais eficiente. Em ambiente real, há vários nós entre cliente e servidor, logo há um maior tempo de
resposta natural. Um servidor real quase sempre possue uma aplicação ou um sistema web em execução, que consome mais recursos do servidor
facilitando a negação de serviço. Além disso, há tráfego externo e outros clientes que irão ocupar banda, atrasar pacotes e que 
também irão consumir
mais recursos do servidor. Esses acrécimos podem ser a diferença entre uma negação de serviço total e parcial, confirmando a viabilidade
de ataques do gênero.

Como parte da análise do ataque e para um melhor entendimento é importante classificá-lo. As ferramentas de ataque assim como
apresentadas podem ser classificadas como um ataque de negação de serviço (DoS) degradante que causa uma negação parcial de serviços.
O ataque também é considerado como um ataque de conteúdo que visa o uso previsto do protocolo para consumir o CPU da vítima. A vítima do ataque
sofre oscilações na negação de serviço, não possuindo nenhum caráter constante, porém o ataque é caracterizado por ter sempre um fluxo constante.

\section{Sugestões para a evolução do ataque}
Observando os resultados, fica claro que as ferramentas de ataque obtiveram resultados diferentes e algumas ferramentas se 
destacaram das demais. Essas ferramentas podem ser trabalhadas, por exemplo, para se montar um ataque de negação de serviço distribuído(DDoS)
aumentando drasticamente o poder do ataque. As ferramentas chegaram a obter resultados capazes de atrapalhar qualquer cliente, usando
de algumas modificações e incrementos as ferramentas podem, com certeza, realizar uma negação de serviço total e disruptiva.

Para melhorar as defesas contra o ataque é necessário levar em conta a evolução do ataque e para onde ele caminha, para evitar ser pego
desprevinido. Comparando as ferramentas que usavam \emph{threads} e QT\textregistered fica claro que uma abordagem menos discreta e mais
rápida possue melhores resultados, olhando as ferramentas que usam libevent percebe-se um maior ganho no aumento do número de conexões
e no tempo de resposta. Juntando o melhor das duas ferramentas supõe-se que criar uma ferramenta usando as funções de sistema e paralelismo
da API libevent junto com a abordagem da ferramenta que não espera respostas do servidor pode criar uma ferramenta de ataque mais poderosa.
Essa ferramenta precisaria de algumas modificações na API libevent para garantir que a mesma não esperasse eventos(resposta do servidor) ou
que usasse um evento de \emph{timer} bem curto. Executar o ataque de mais de uma máquina assim como os DDoS também pode aumentar o perigo
do ataque.

\section{Possíveis contramedidas}
O ataque não pode ser diretamente evitado, pois o ataque usa corretamente do protocolo TLS/SSL e uma vez que o pacote com 'lixo' é decifrado,
o gasto de CPU do servidor já ocorreu e evitar o pacote errado não é mais viável. Um \emph{handshake} TLS/SSL normal pode falhar
naturalmente o que deixa impossível de se prever se o pacote com 'lixo' foi intencional. Entretanto, o ataque pode ser detectado e 
se detectado, pode ser evitado com o uso de uma \emph{firewall} usando uma \emph{web application} que registre estatísticas de falhas decorrentes de clientes. 

Para detectar o ataque basta usar estatísticas do servidor para medir erros de 
decifração ou contar alertas TLS/SSL emitidos, compara-se em seguida essas estatísticas com os valores que normalmente são obtidos,
em caso de discrepância, um ataque pode estar ocorrendo. Esses valores para comparação podem
ser obtidos de forma estática, automática e semi-automática. Para mais detalhes sobre as vantagens e desvantagens na escolha de limiares 
de comparação, verificar o capítulo 3 e a subseção de mecanismos de defesa.

Uma solução reativa(após a detecção) proposta para impedir o ataque é o uso de uma firewall bloqueando o atacante. Como o atacante tem que estabelecer uma
conexão TCP para começar o ataque, não há a possibilidade de \emph{ip spoofing} e logo o endereço IP do atacante é revelado. Essa solução aumenta
o tempo de resposta do servidor pois o mesmo começa a filtrar usuários um por um, o que em alguns casos ajuda o atacante. Essa solução, entretanto, não é perfeita, pois uma
versão bem feita do ataque como DDoS(ataque distribuído com várias máquinas) pode simplesmente alternar entre as máquinas atacantes infectadas para evitar detecção ou atravessar o
bloqueio da firewall. Toda solução de bloqueio, no entanto, pode acabar por bloquear tráfego legítimo devido a falsos positivos.


Uma outra solução é aumentar a capacidade do hardware do servidor para que o mesmo consiga executar suas funções mais rápidas e mais eficientes e suporte
o ataque sem trazer consequências danosas aos clientes. Essa solução resolve quase todos os tipos de DoS, porém é meio utópica pois exige um
alto custo financeiro e às vezes, tecnologia ainda não disponível. Em vez de melhorar o hardware do servidor, também pode-se usar aceleradores
de SSL. Esses aceleradores aumentam o desempenho de funções criptográficas, porém também possuem custo e apenas mitigam o ataque.

Um ponto importante é o uso de \emph{cipher suites} adequadas, elas possuem tempo de respostas diferentes em cada servidor e escolher
as certas podem mitigar os efeitos do ataque ou aumentá-lo. Vale a pena executar um teste de desempenho no servidor e ponderar entre
desempenho e segurança, para escolher quais \emph{cipher suites} são ideais de serem disponibilizadas aos clientes. Esse ponto remete
 à polêmica envolvendo a NSA~\cite{nsa} e a discussão sobre o uso de \emph{perfect foward secrecy}. Analisando os resultados pode-se
 reparar que o uso de \emph{perfect foward secrecy} aumenta consideravelmente o potencial do ataque, então não há muito o que se discutir,
 tudo se resume ao dilema entre segurança e eficiência. O uso de protocolos com Diffie \& Hellman efêmero tem um alto custo computacional
 e considerável fragilidade de disponibilildade(em caso de ataques DoS)
 em troca de sua maior segurança criptográfica.

 Levando em conta todos os pontos citados, pode-se dizer mais uma vez que o ataque de negação de serviço proposto é viável e pode ser
 usado com intenções maliciosas. As ferramentas aqui propostas podem inclusive ser melhoradas para um maior impacto, por isso são necessárias
 medidas para se defender do ataque. Algumas sugestões foram propostas, mas outras devem ser propostas e testadas. Encerra-se este documento
 com um apelo em prol da segurança de redes e sua importância no mundo moderno.